home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 090 / ozbext.arc / OZBEXT.TXT < prev   
Text File  |  1988-03-03  |  10KB  |  211 lines
  1. OZBEXT Short Docs       03/03/88
  2. --------------------------------
  3. OZBEXT version 3.7x  Copyright(c)1987,1988 Steve Sneed/Ozarks West Software
  4. Placed in the public domain by the author.
  5.  
  6. ============================================================================
  7.  
  8.  
  9. Syntax
  10. ------
  11.  
  12. OZBEXT [port] [baud] [parity] [data bits] [stop bits] {-x} {-v} {-d}
  13.  
  14. Params in square brackets are required, those in curly braces are optional.
  15.  
  16. REQUIRED PARAMETERS:
  17. port: 1,2,3,4 - the standard COM number for the port in use.  COM 3 & 4 at the
  18.         "standard" address for these devices: COM3 - IRQ4, 03E8h
  19.                                               COM4 - IRQ3, 02E8h
  20. baud: 300,1200,2400,4800,9600,19200.  CTS support for high-speed modems -
  21.         CTS monitoring automatically implemented above 4800 baud.
  22. parity: N,E,O,M,S.  None, Even, Odd, Mark, Space.
  23. databits: 5,6,7 or 8 (almost always 7 or 8).
  24. stopbits: 1 or 2 (almost always 1).
  25.  
  26. OPTIONAL PARAMETERS:
  27. -x: if set, causes OZBEXT to return to it's own terminal mode after the com-
  28.     pletion of a Standard B transfer or the completion of a QuickB file
  29.     transfer.  The default is to exit back to the calling program.
  30.     Note that QuickB "Applications Packet" and "Transport Parameters Packet"
  31.     transfers do not invoke this exit.
  32. -v: if set, causes OZBEXT to use the CIS "VidTex" terminal emulation for cur-
  33.     sor positioning.  The default is to emulate an ANSI graphics terminal.
  34. -d: if set, causes OZBEXT to drop DTR on exit, hanging up any call in progress.
  35.     The default is to leave DTR high on exit so connection is not broken when
  36.     returning to the calling program.
  37. -s: if set, uses "silent" mode.  Default is to use audible warnings.
  38. -h: if set, uses half-duplex mode.  Default is full-duplex.
  39.  
  40.  
  41. Use
  42. ---
  43.  
  44. This program was designed to be called from within another comm program to
  45. add support for the CIS "B" and "QuickB" protocols and simple VidTex term
  46. emulation.  Examples of programs with this capability are Boyan and OzCom5.
  47. The program can also be used with most any commware that has a "Shell to DOS"
  48. capability.  When using OZBEXT with a program that has "Shell-to-DOS" but
  49. does not directly support external modules, it is suggested that you create
  50. a batch file calling the program with the correct parameters.
  51.  
  52. In order for the program to function, it must be loaded prior to requesting
  53. the transfer from CIS.  CIS "interrogates" your program when a "B" protocol
  54. transfer is requested, and unless this program is running it will not be
  55. responded to properly.  Where possible, it is suggested that you load OZBEXT
  56. as soon as possible after logging on to CIS, using the "-X" command-line
  57. switch, and stay in OZBEXT for the duration of the call.
  58.  
  59.  
  60. Commands
  61. --------
  62.  
  63. The following keystroke commands are available within OZBEXT:
  64.  
  65. Alt-Z : Clears the screen.
  66. Alt-X : Exits OZQB.
  67.  
  68.  
  69. "B" Protocol
  70. ------------
  71.  
  72. OZBEXT fully supports both standard "B" and the new "QuickB" protocols.
  73. Detection of protocol type and transport parameter setting is fully
  74. automatic.
  75. To abort a transfer in progress, use ^X (NOT Alt-X!)  The setting of the
  76. -x parameter is respected.
  77. Note that CompuServe normally logs on at 7 bits/Even parity, while the "B"
  78. protocols require 8 bits/No parity.  The switching of these parameters for
  79. the transfer is automatic.
  80.  
  81.  
  82.  
  83. Upgrades
  84. --------
  85.  
  86. * (3.71) Two figures are now displayed at the end of a transfer - the overall
  87.   transfer rate and the effective rate.  The overall rate is the average bytes
  88.   per second for all bytes sent or received during the transfer, while the
  89.   effective rate is for the actual contents of the file sent/received.
  90.   Because of the way the B/QB protocols use "masking" bytes, and because of
  91.   at least 2 extra packets containing control information only, there will
  92.   almost always be a difference between the two figures - a difference that
  93.   usually will increase somewhat as the size of the transfered file increases.
  94.   While the effective rate is the true measure of worth for any transfer, the
  95.   quest for the highest possible bytes/second number leads most programmers
  96.   to use the overall figure.  So that my programs will appear "competitive",
  97.   I provide the overall figure, but I suggest that you use the effective rate
  98.   number when comparing actual transfers.
  99.  
  100.  
  101. Comments
  102. --------
  103.  
  104. Thanks to IBMNet SysOps Connie Kageyama and Don Watkins for the idea for this
  105. program.
  106.  
  107. This program was designed to be as small and compact as possible - there are
  108. darn few "bells and whistles".  It's "big brother" OZQB (also available here
  109. and elsewhere) has many added features such as RLE graphics support on most
  110. any monitor, "Split-Screen" mode for easy conferencing, full function key
  111. support, Shell-to-DOS capability including calling other external protocol
  112. modules such as DSZ, automatic VidTex/ANSI support selection and more.  It is
  113. quite a bit larger and requires at least 450K when called from within another
  114. comm program (192K stand-alone) but is still small enough and quick enough
  115. to be used as a called module on the typical 512K - 640K system.  If you like
  116. this program but need the added capabilities, try OZQB.
  117.  
  118. With the release of OZQB, the two programs will take different directions -
  119. OZBEXT will continue to be small and compact, providing only the minimum
  120. functions nessessary in support of "B" and "QuickB", while OZQB will be the
  121. "featureitis" version.  I am also working on a new version of OzCom for the
  122. full-featured commware user.
  123.  
  124. This program was written completely in Turbo Pascal 4.0.
  125.  
  126. Enjoy!
  127.  
  128.                                      Steve Sneed
  129.                                      71520,77
  130.                                  or
  131.                                      The C2G BBS
  132.                                      805-922-3318  3/12/24  24hrs
  133.                                      FidoNet Node 102/2872
  134.  
  135.                                  U.S. Mail:
  136.                                      Computers To Go
  137.                                      1539 S. Broadway
  138.                                      Santa Maria, CA.  93454
  139.  
  140. =============================================================================
  141.  
  142. Starting with this release of this document, I will attempt to add information
  143. concerning specific comm programs that may possibly have problems with OZBEXT,
  144. or answer questions about OZBEXT and other comm programs.
  145.  
  146. SmartCom (versions II and III):  This program does some really wierd things
  147.   with both the serial port and the video.  Since OZBEXT does *all* of its
  148.   screen output thru DOS via DOS service 06h, and I do not have access to the
  149.   inner workings of the various versions of SCom, I can't say why a video
  150.   lockup occurs when SCom returns from OZBEXT... but video lockup it does.
  151.   The port still functions normally (after much work) and is properly re-
  152.   initialized on return, but still no video.  Final recomendation: do NOT
  153.   use OZBEXT with SCom unless you intend to use OZBEXT for the entire CIS
  154.   session.  You will be forced to exit SCom after returning from OZBEXT.
  155.  
  156. BitCom (various versions):  BitCom has changed a great deal across versions in
  157.   the port-handling and port-reset-on-return-from-shell areas.  Earlier ver-
  158.   sions (2.6 et al) do not reset the port on return from a shellout, which
  159.   causes BitCom to seemingly lock up on return.  A simple way to cure this
  160.   is to, on return, use BitCom's parameter-setting function to change the
  161.   port params from 8/N/1 to 7/E/1 (or vice versa) and back.  This resets the
  162.   port and returns control to BitCom.  Note that you may loose a few char-
  163.   acters from the host while you do this switch.  Also, this is another
  164.   program that I recomend you use OZBEXT in -X mode and stay within OZBEXT
  165.   while connected to CIS.
  166.  
  167. SmartTerm 220/240 (latest versions):  OZBEXT works fine with these programs.
  168.   While they are primarily terminal emulators (exellent ones!) and are seldom
  169.   used as modem communications programs, some folks use 'em for both.
  170.  
  171. PROCOMM ("Plus" version and earlier):  While version 2.4.2 of this program's
  172.   B implementation seems to work OK, earlier versions and the new "Plus"
  173.   version's B protocol is full of bugs.  You definately should use OZBEXT
  174.   or another external B module with PROCOMM.  PROCOMM's shellout function
  175.   presents no known problems.
  176.  
  177. QModem, Boyan, OzCom5:  All of these programs work fine with OZBEXT and every
  178.   other external module for any protocol type known.  They should - they were
  179.   designed for external modules!  I've used QModem in its various releases
  180.   for years and know John Friel's program to be rock-solid.  Boyan, while
  181.   lacking some of the bells-and-whistles of some of the other comm programs,
  182.   is by far the smoothest and friendliest commware around for the novice to
  183.   medium-power user.  OzCom5... well, I wrote it.  Oh, yes... Telix 2.12 is
  184.   another exellent program that supports OZBEXT and other external modules
  185.   nicely.
  186.  
  187. AutoSIG and TAPCIS:  Don't waste your time with OZBEXT.  Both of these pro-
  188.   grams have exellent B protocol implementations internally.  They are de-
  189.   signed exclusively for CIS use and provide many features no other comm
  190.   programs can match for accessing CompuServe.  TAPCIS does a few things
  191.   AutoSIG will not, while AutoSIG is free and TAPCIS is shareware at $79.
  192.   Take your pick - you won't be disappointed with either.
  193.  
  194.  
  195. -----
  196.  
  197. If you use OZBEXT with a program (especially commercial) not listed here,
  198. please drop me a note at one of the above addresses letting me know how it
  199. works for you.  If you have a problem, don't hesitate to let me know that
  200. either.  While I'm a very busy man, I'll do what I can to help you.  Connie
  201. Kageyama, Co-SysOp of IBMNet on CIS, has been extremely helpful while I
  202. developed and debugged this program (as have all of the IBMNet SysOps!) and
  203. can also provide you with help and information.  I can respond much faster to
  204. messages sent either directly to my board or to my board via FidoNet NetMail.
  205.  
  206. Thanks!
  207.  
  208. Steve
  209.  
  210. <eof>
  211.